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CONSISTENCY  CHECKS  FOR  SCR-STYLE 
REQUIREMENTS  SPECIFICATIONS 


INTRODUCTION 

•The  significant  human  eflort  required  to  detect  and  correct  software  errors  accounts  for  a 
large  portion  of  software  costs.  Many  software  errors  are  introduced  during  the  early  stages 
of  software  development — luring  requirements  definition  and  functional  analysis.  However, 
most  are  not  discovered  until  much  later — during  coding,  testing,  and  initial  operational  use 
of  the  software  [1].  Unfortunately,  the  later  they  are  discovered,  the  more  expensive  software 
errors  are  to  correct.  Errors  discovered  late  can  cost  up  to  one  hundred  times  as  much  to  fix 
as  errors  discovered  during  the  requirements  stage  [2,3]. 

To  reduce  software  costs  and  to  increase  software  quality,  new  methods  are  needed  that 
help  developers  detect  and  correct  errors  early  in  the  software  development  process,  especially 
during  the  requirements  stage.  Our  interest  is  in  formal  methods,  i.e.,  mathematically  based 
techniques  useful  in  developing  computer  systems.  Formal  methods  can  provide  a  sound 
basis  for  building  software  tools  that  analyze  software  requirements  specifications  for  errors. 

An  important  question  is  what  form  these  tools  should  take.  To  help  answer  this  ques¬ 
tion,  we  are  developing  a  prototype  toolset  for  constructing  and  analyzing  software  (and 
system)  requirements  specifications.  Our  toolset  includes  tools  that  help  developers  gener¬ 
ate  formal  requirements  specifications,  tools  that  use  the  formal  specifications  to  simulate 
system  operation,  and  “verification”  tools,  i.e.,  tools  to  help  verify  that  the  specifications 
have  selected  properties. 

Three  different  classes  of  verification  can  be  applied  to  requirements  specifications.  One 
class  compares  the  requirements  specifications  with  a  refinement.  The  refinement  can  take 
many  forms,  such  as  a  set  of  software  design  specifications,  as  in  Moore’s  verification  of  the 
abstract  voice  transmitter  [4],  or  a  set  of  code  specifications,  as  in  the  recent  Canadian  effort 
to  certify  the  Darlington  nuclear  plant  shutdown  systems  [5].  A  second  class  of  verification 
checks  requirements  specifications  for  selected  application  properties.  For  example,  in  a 
railroad  crossing  system,  a  certain  property  must  hold  in  every  state:  the  crossing  gate  must 
be  down  if  a  train  is  in  the  crossing  [6].  The  preceding  is  an  example  of  a  logical  property. 
Other  important  types  of  application  properties  are  security  properties  (e  g.,  [7])  and  timing 
properties  (e.g.,  |8|). 

A  third  class  of  verification,  which  we  call  consistency  checking,  is  the  subject  of  this 
report.  A  consistency  checker  tests  the  consistency  of  requirements  specifications  with  a 
formal  model.  The  model  defines  the  properties  of  a  large  class  of  requirements  specifications. 
Although  the  properties  tested  by  a  consistency  checker  are  usually  quite  simple  (e  g.,  check 
that  a  total  function  F  is  defined  everywhere  in  F’s  domain),  the  number  of  times  a  property 
must  be  checked  in  a  set,  of  requirements  specifications  can  be  very  large,  and  thus  human 
reviewers  may  spend  considerable  time  and  effort  verifying  that  the  specifications  have  the 
properties.  In  fact,  in  the  certification  of  the  Darlington  nuclear  plant  shutdown  systems, 
Parnas  has  observed  that  t  he  "reviewers  spent  too  much  of  t  heir  t.une  and  <_:ierg.v  checking  for 
simple,  application-independent  properties”  (such  as  checking  for  domain  coverage)  which 
distracted  them  from  the  “more  difficult,  safety-relevant,  issues”  [9|.  Tools  that  automatically 
perform  such  checks  can  save  reviewers  considerable  time  and  effort  Moreover,  they  can 
detect  errors  often  overlooked  by  human  reviewers  (see  below). 

Manuscript  approved  December  21,  1993. 
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In  this  report,  we 

•  introduce  our  formal  requirements  model,  which  is  based  on  the  SCR  (Software  Cost 
Reduction)  approach  to  requirements; 

•  identify  a  set  of  consistency  checks  derived  from  the  model;  and 

•  describe  two  experiments  we  conducted  to  determine  the  utility  of  automated  consis¬ 
tency  checking. 

Our  experiments,  which  checked  the  consistency  of  the  software  requirements  specificat  ions 
for  a  Navy  avionics  system,  detected  a  significant  number  of  errors  despite  the  fact  that 
the  specifications  had  previously  undergone  comprehensive  checks  by  human  review  teams. 
These  results  provide  convincing  evidence  of  the  utility  of  automated  consistency  checking. 

BACKGROUND:  FORMAL  REQUIREMENTS  MODEL 

The  SCR  approach  to  requirements  specification  is  the  basis  for  our  requirements  model. 
Developed  originally  by  Heninger,  Parnas,  and  Shore  [10-12]  to  specify  software  requirements, 
the  approach  was  recently  extended  by  Parnas  and  van  Schouwen  to  describe  system-level 
requirements  [  1 3, 1 4 J.  Major  goals  of  the  SCR  approach  are  to  increase  the  precision  and 
reduce  the  implementation  bias  of  requirements  specifications  [15].  To  achieve  scalability, 
the  SCR  approach  uses  a  tabular  notation  that  produces  concise  yet  readable  requirements 
specifications.  Recently,  the  SCR  requirements  approach  was  used  in  the  certification  of  the 
Darlington  systems  cited  above. 

Underlying  the  SCR  approach  to  requirements  specification  is  a  finite-state  machine 
model  that  describes  the  required  relation  between  the  computer  system  of  interest  and  its 
environment.  Our  goal  in  [16]  is  to  make  that  model  explicit  so  that  we  have  a  sound  basis  for 
building  tools.  The  model  is  built  out  of  a  few  basic  SCR  constructs,  including  monitored  and 
controlled  state  variables,  system  modes,  terms,  conditions,  and  events.  In  this  section  we 
describe  these  constructs  informally,  introduce  our  formal  requirements  model,  and  provide 
formal  definitions  of  two  SCR  table's  to  illustrate  the  model.  In  the  discussion  below,  we  refer 
to  monitored  and  controlled  state  variables,  system  modes,  and  terms  as  state  variables. 

Constructs  for  Requirements  Specification 

The  objective  of  a  requirements  specification  is  to  capture  all  acceptable  implementations 
of  a  computer  system  [17],  To  the  extent  feasible,  the  specifications  should  be  abstract, 
describing  only  the  externally  visible  behavior  required  of  the  system.  Two  constructs  that, 
help  make  the  specifications  abstract — monitored  and  controlled  state  variables  -  represent 
the  entities  of  interest  in  the  system’s  environment  [13,14].  A  monitored  state  variable 
represents  an  environmental  entity  that  can  cause  the  system  to  t  ake  some  action.  Changes 
in  the  monitored  variables  provide  stimuli  to  the  system.  The  controlled  state  variables 
represent  environmental  entities  that  the  system  changes  in  response  to  the  stimuli.  For 
example,  in  a  control  system  that  monitors  water  temperature  and  sounds  an  alarm  when  the 
temperature  exceeds  some  threshold,  water  temperature  would  be  represented  as  a  monitored 
state  variable,  the  alarm  as  a  controlled  state  variable. 

Other  useful  constructs  for  specifying  requirements  are  conditions  and  events.  A  condition 
is  a  predicate  about  the  system  that  is  true  (or  false)  for  some  measurable,  nonzero  time 
interval.  Conditions  are  predicates  on  state  variables;  in  the  control  system  described  above, 
“WaterTomp  <  Threshold"  is  an  example  of  a  condition.  A  primitive  event  occurs  when  a 
state  variable  changes  value.  A  special  primitive  event  called  a  monitored  event  occurs  wh-n 
monitored  state  variable  changes  value  In  the  control  system  above,  a  change  in  water 
temperature  that,  exceeds  the  specified  threshold  marks  the  occurrence  of  a  monitored  event 
(given  that  the  temperature  was  not  greater  than  the  threshold  before  the  change).  The 
occurrence  of  this  event  would  cause  the  system  to  sound  an  alarm. 


Consistency  Checks  for  SCR-Style 


3 


System  modes  and  terms  help  simplify  the  specifications.  A  mode  class  is  a  state  machine, 
whose  states  are  called  system  modes  (or  simply  modes)  and  whose  transitions  are  triggered 
by  events.  Complex  systems  are  defined  by  more  than  one  mode  class,  operating  in  parallel. 
At  any  given  time,  a  system  must  be  in  exactly  one  mode  from  each  modi'  class  In  the  cont  roi 
system  example,  two  system  modes  can  be  identified,  “normar  mode  and  "hazardous"  mode 
A  high  water  temperature,  a  hardware  fault,  or  some  other  event  can  cause  the  system  to 
move  from  “normal”  mode  to  “hazardous"  mode.  Clearly,  tire  required  system  behavior 
in  normal  mode  will  be  different  from  system  behavior  in  the  hazardous  mode.  If  at  any 
given  time,  the  control  system  must  be  in  either  normal  mode  or  hazardous  mode,  then 
these  two  modes  form  a  mode  class.  Each  term  is  a  function  of  monitored  state  variables, 
modes,  or  other  terms.  In  the  control  system  example,  the  system  may  use  three  sensors  to 
measure  water  temperature.  To  express  the  control  system’s  requirements,  a  term  named 
MajorityHigh  may  be  defined  that  has  the  value  true  if  two  or  more  sensors  indicate  a 
temperature  above  the  threshold,  false  otherwise. 

Summary  of  the  Formal  Model 

Reference  16  contains  an  initial  version  of  our  formal  requirements  model,  hike  the  model 
introduced  by  Faulk  [18],  our  model  describes  a  computer  system  as  a  finite-state  automaton 
(S,  so,  E,T),  where  .S’  is  a  set  of  system  states,  so  is  an  initial  state,  E  is  an  input  alphabet 
consisting  of  monitored  events,  and  T  is  a  system  transform  describing  the  changes  that 
monitored  events  trigger  in  the  system  state.  In  the  model,  the  system  state  s  is  a  set  of 
ordered  pairs,  s  {(r.  »>)},  where  r  is  the  name  of  a  monitored  or  controlled  state  variable,  a 
mode  class,  or  a  term,  and  r  is  a  value.  The  state  ,<s  is  treated  as  a  function,  where  s(r)  v 
iff  (r.v)  e  s. 

A  fundamental  assumption  of  our  initial  model  is  that  the  system  transform  T  is  a  func¬ 
tion.  For  some  applications,  this  assumption,  which  forces  the  requirements  specificat  ions  to 
be  deterministic,  is  overly  restrictive  and  can  lead  to  overspeeifieat ion, of  the  requirements 
To  avoid  this  problem,  new  versions  of  the  model  will  allow  nondeterminism.  However, 
checking  specifications  for  nondeterminism  still  has  utility.  Instances  of  nondeterminism  in 
the  specifications  should  be  brought  to  the  user’s  attention,  so  that  he/she  can  confirm  that 
the  nondeterminism  is  intentional,  not  an  error. 

To  define  required  system  behavior.  SCR  specifications  (such  as  the  A-7  specifications 
[11]  and  the  Water  Level  Monitoring  System  [11])  use  a  collection  of  tables,  among  them 
selector  tables,  condition  tables,  event  tables,  and  mode  transition  tables.  Our  requirements 
model  uses  functions  to  define  the  meaning  of  these  tables.  The  functions  defining  selector 
tables  and  condition  tables  describe  constraints  on  the  system  state.  A  selector  table  maps 
a  mode  to  an  output  (e  g.,  a  controlled  state  variable)  in  the  same  state;  a  condition  table 
maps  a  mode  and  a  cont  lit  ion  to  an  output  in  the  same  st  ate.  The  functions  that  define  event 
tables  and  mode  transition  tables  describe  constraints  on  the  system's  state  transitions.  An 
event  table  (mode  transition  table)  maps  a  mode  and  an  event  to  an  output  (a  mode)  in  the 
new  state. 

Two  Definitions  from  the  Model 

We  present  two  definitions  from  our  initial  model.  The  first  definition  describes  Un¬ 
meaning  of  condition  tables,  the  second  the  meaning  of  mode  transition  tables  In  the 
definitions.  TY  is  a  function  that  maps  a  state  variable  or  mode  to  its  data  type,  r'  is 
the  name  of  a  mode  class,  and  A/,  is  the  set  of  values  of  mode's  in  that  mode  class  (i.e  . 

TY(r')  A/,). 

Condition  Tables 

In  an  St’lt  requirements  specification,  each  condition  table  defines  a  controlled  state 
variable  or  a  term  as  a  function  of  modes  and  conditions.  All  condition  tables  must  satisf\ 
certain  properties,  including: 
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•  Coverage  Property.  The  disjunction  of  the  conditions  in  a  row  is  true.1  This 
property  forces  the  function  to  be  total. 

•  Mutual  Exclusion  Property.  The  conjunction  of  any  pair  of  conditions  in  a  row  is 
false.  Otherwise,  the  definition  does  not  describe  a  function 

Below,  we  show  one  possible  format  for  a  condit  ion  table  in  an  SCR  specification  and  present 
a  function  which  describes  the  table's  meaning.  The  function  definition  consists  of  the  table's 
syntax,2  its  semantics,  and  a  set  of  constraints,  including  the  two  properties  listed  above. 
The  purpose  of  the  constraints  is  to  ensure  that  the  definition  conforms  to  the  formal  model 


Modes 

Conditions 

mi 

Cl.l 

C\ ,2 

tr.|> 

771  o 

C'2 . 1 

C'2, 2 

c-i.r 

771  n 

Cn.l 

l'n,2 

,p 

r 

t’i 

t’2 

rP 

Syntax:  A  condition  table  is  a  function  Fr{iiij , <:jk )  c*.  where  r  is  a  controlled  state 

variable  or  term,  nij  is  a  mode  in  mode  class  A/,,  cjk  is  a  condition,  and  vk  is  a 
value. 

Semantics:  jn  state  s,  s(r')  nij,  there  exists  k:  is  /rue  in  state  s, 

and  FT(mj.rj  k)  rk  ,s(r)  rk. 

Constraints: 

(1)  For  all  j,  v£  jCj.h  true  (Coverage  Property). 

(2)  For  all  j,k,k',k  /  k' :  cjk  A  cJ>k-  false  (Mutual  Exclusion  Property). 

(3)  The  modes  m3  are  distinct,  and  uj!  ( nij  A/,. 

(4)  For  all  j,  e  TY(r)  (Type  Checking). 

Mode  Transition  Tables 

An  SCR  requirements  specification  contains  one  mode  transition  table  for  each  mode 
class.  Each  mode  transition  table  defines  a  new  mode  as  a  function  of  tin'  current  mode 
and  a  conditioned  event.  In  our  formal  model,  a  conditioned  event  is  an  ordered  pair  (c.c), 
where  e  is  a  primitive  event  and  e  is  a  condition.  A  conditioned  event  (r,  c)  occurs  in  state  .< 
when  event  e  occurs  in  state  s  and  condition  r  is  true  in  state  .•».•*  As  with  condition  tables, 
functions  defined  by  mode  transition  tables  must  satisfy  specified  constraints.  For  example, 
each  event  and  current  system  mode  must  be  mapped  to  a  unique  neiy  system  mode  ( i . e  , 
the  next-state  mapping  is  deterministic ).'*  Below,  we  show  a  possible  format  of  a  mode 
transition  table  in  an  SCR  specification  and  present  a  function  defining  the  tallies  meaning. 


'As  P.  Clements  has  observed,  the  Coverage  Property  may  not  hold  when  dependencies  among  the  state 
variables  are  referred  to  in  the  conditions  (t'.tj 

2This  definition  requires  all  modes  appearing  in  a  condition  table  to  belong  to  the  same  mode  class  the 
A-7  requirements  document  contains  examples  of  condition  tattles  in  which  the  modes  do  not  all  belong  to 
the  same  mode  class 

'  I  n  the  SCR  approach,  the  simple  event  represent  I'd  as  itT(A)  means  "condition  A  becomes  true";  the 
simple  conditioned  event  represented  by  <VI’(A)  WIIF.N  H  means  "condition  A  becomes  true  when  condition 
If  is  true"  The  simple  event  *•!■’( A )  ran  be  representeil  as  A) 

4This  is  required  for  the  function  to  lie  well-defined  Note  that  this  property  is  identical  to  the  Mutual 
Exclusion  Property.  Eor  historical  reasons,  we  refer  to  this  property  as  Determinism  when  discussing  mode 
transition  tables 
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Current 

Set  of 

New 

Mode 

Conditioned  Events 

Mode 

7)1 1 

Ei.  i 

ci  1.1 

F.2 

77)i,2 

Fi.Ji 

™l.Jt 

m  2 

7?2,1 

C12.I 

771 2 .2 

E2.J2 

m2.j2 

mp 

Fp.i 

Clp.i 

F,<:> 

Clp,2 

Fp.Jp 

mr.JP 

Syntax:  Tho  mode  transition  table  for  the  mode  elass  associated  with  r'  is  a  function 
FT’{m.ky  Ek.Jk )  -  tnk.Jk.  where  mk  and  mkjk  are  modes  in  mode  class  M,.  and 
Ek  ]k  is  a  set  of  conditioned  events. 

Semantics:  Given  states  s  and  .s’,  s(r')  -  mk,  there  exists  jk:  conditioned  event  e  €  Ek.n 
occurs  in  state  s,  and  FT'(mk,Eki Jk)  =  mk  jk  — *  s’(r')  --  mk>]k. 

Constraints: 

(1)  The  modes  mk  are  distinct. 

(2)  For  all  k,  jk ,  j'k,  jk  f  j'k  :  (e,c)  €  Ek,Jk,  (e',c')  6  Ek.fk< 

mk  ]k  7 ^  end  -  0  OR  c  A  c'  -  /a/.se  (Determinism).5 

(3)  mgilfj  — *  3k\  1  <  k  <  p:  m  =  mk  V  3/e,  1  <  fc  <  p,  3jk.  1  <  jk  <  Jk  :  m  --  7ii/<Jt 
(each  mode  in  the  mode  class  M,  is  in  either  F-.’s  domain  or  its  kernel). 


RESULTS  OF  APPLYING  CONSISTENCY  CHECKS 

We  conducted  two  experiments  to  evaluate  the  utility  of  applying  consistency  checks  to 
requirements  specifications.  In  the  experiments,  software  tools  were  constructed  and  used 
to  check  tables  in  an  updated  version  [12|  of  the  A-7  requirements  document  (1 1|.  By  means 
of  a  collection  of  tables,  this  document  specifies  the  required  behavior  of  the  A-7E  aircraft's 
Operational  Flight  Program  (OFP),  a  program  containing  approximately  16,000  lines  of  very 
tight  assembly  language  code.  The  new  document  [12]  corrects  several  errors  in  the  original 
and  uses  a  tabular  format,  designed  by  Faulk  (18],  to  specify  mode  transitions.  Advantages 
of  the  new  format  are  improved  readability  and  increased  amenability  to  automated  analysis. 

The  checks  that  we  applied  to  condition  tables  and  mode  transition  tables  and  the  sig¬ 
nificant  numbers  of  errors  that  the  tools  uncovered  are  described  below.  We  also  compare 
tool-based  consistency  checking  with  manual  consistency  checking  and  discuss  the  relation¬ 
ship  between  our  work  and  other  recent  work  analyzing  SCR-style  specifications.  Table  2 
below  refers  to  input  data  items  (indicated  by  the  notation  /.../).  Whereas  monitored  state 
variables  represent  system  inputs,  input  data  items  represent  software  inputs.  In  the  control 
system  described  above,  water  temperature  would  be  denoted  by  a  monitored  state  variable, 
the  reading  of  a  sensor  that  measures  water  temperature  by  an  input  data  item 


'This  check  for  nondeterminism  does  not  cover  all  cases.  For  example,  it  cannot  detect  nondeterminism 
that,  occurs  because  of  dependencies  among  events  An  instance  of  this  occurs  when  two  events  are  both 
triggered  by  a  third  event  but  are  also  both  triggers  of  change  (conditioned  events)  in  a  mode  table  Although 
our  tool  did  not  detect  it,  automated  detection  of  this  class  of  nondeter niinism  is  possible 
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Checks  on  Condition  Tables 

In  the  first  experiment,  we  constructed  a  tool  that  checked  all  of  the  condition  tables  in 
Ref.  12  for  the  two  properties  described  previously  the  Coverage  Property  and  the  Mutual 
Exclusion  Property.  All  of  the  condition  tables  in  the  specifications  Mi  tables  consisting 
of  98  rows  were  tested.  Our  tool  found  19  errors  Seventeen  of  these,  distributed  over  11 
tables,  proved  to  be  legitimate  errors.  Table  1  shows  the  four  types  of  errors  that  were  found, 
the  number  of  instances  of  each  error,  and  a  description  of  the  error. 

Our  tool  only  checked  the  variables  in  condition  tables  that  were  Boolean  *'  Therefore, 
it  did  not  have  enough  information  to  determine  that  two  of  the  flagged  errors  were  not 
truly  errors.  Both  cases  involved  three  values,  namely.  IMarkl.  ’Best  0!  and  !I)est  1-9!. 
which  describe  combinations  of  set  tings  of  two  input  devices  These  three  values  are  all  the 
possible  values  and  do  not  overlap.  We  confirmed  by  hand  that  the  two  rows  containing 
these  terms  are  correct. 


Table  1  —  Errors  Detected  in  the  A-7E  Condition  Tables 


ERROR 

INSTANCES 

EXPLANATION 

Slewing  Variable 

9 

While  behavior  for  2  of  the  3  values  of  the  variable 
Slewing,  namely,  ! Before  slewing!  and  'After  slewing', 
is  specified, behavior  for  third  value,  f During  slewing', 
is  missing. 

‘GrTest* 

4 

‘GrTest*  is  a  mode  with  subivmdes.  Some  tables  do 
not  specify  behavior  for  all  the  ‘GrTest*  subimxles 

Steering  Phases 

3 

In  early  document,  3  values  were  used  to  describe 
phases  of  steering  to  a  target.  In  revised  document, 

4  values  used  but  some  tables  have  not  been  updated 

Application- 

Specific 

Knowledge 

1 

"  !OTS!  OK  ! Range  to  RMAXlcO"  and 
"NOT  (Irange!  to  (target!  <=  10  miles)" 
do  not  form  a  partition. 

Checks  on  Mode  Transition  Tables 

In  a  second  experiment,  we  built  a  tool  that  checked  all  of  the  mode  transit  ion  tables  defined 
in  Ref.  12  for  nondeterminism  The  A -7  specifioat ions  contain  three  mode  classes,  with  lb 
different  modes  distributed  among  them  (In  modes  m  the  first  mode  chiss.  7  modes  in  the 
second,  and  21  modes  in  the  third)  I  lie  tool  checked  (Inn  rows,  each  row  containing  a  simple 
event  or  the  conjunction  of  an  event  and  one  or  more  conditions  Thirty-three  transitions 
were  found  to  be  liondeicrmimstic  Although  many  of  these  transitions  are  undoubtedly 
errors,  a  few  probably  are  not.  since  some  of  the  detected  events  iii.'iv  be  impossible 


*’()f  t  ho  41  vnriaMi*  iis«*d  in  th«*  condition  t;il>h*s.  A.\  v.iri.iblos  won*  <>f  t  >  | >« ■  Boofom  < >r  wrr»*  ronvortoil  li\ 
hand  tx>  typo  Boolean  (  I  In*  latter  wen*  either  modes  or  enumerated  types  with  two  values  >  I  he  remaining 
11  variabh*.  which  were  either  rout  ililMiiis  or  enumerated  with  more  than  two  values,  were  Used  ih  telational 
expressions  The  relational  expressions  weie  also  converted  manualis  into  Boolean  \.at  iahl*ts 

Another  r  lass  of  nondeterminism  is  nondeterminism  involving*  simultaneous  events  Alt li« >111* h  out  tool 
w;is  not  desit»n»,«l  to  detect  this  class  of  nondeterminism.  automat  ir  detection  of  nondeteiminism  caused  l  >\ 
simultaneous  event.s  is  fe.isihle 
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To  illustrate  this  class  of  errors.  Table  2  shows  two  instances  of  nondeterinmisin  detected 
by  the  tool  in  the  mode  transition  table  for  the  Alignment,  Navigation,  and  Test  Mode  Class 
(Table  2  shows  only  a  small  part  of  the  mode  transition  table  In  Kef,  12,  the  complete  table  is 
distributed  over  11  pages.)  The  transitions  that  are  marked  allow  the  system  to  transfer  from 
Inertial  Mode  (*!*)  to  either  Airborne  Alignment  Mode  (*Airaln*)  or  to  Doppler  Inertial 
Mode  (*DI*)  An  example  of  an  event  that  could  trigger  either  transition  is 

<7 T(! Doppler  Up! )  W’HFN  NOT  !CA  stage  complete!  A  NOT  'present  position  entered' 

A  'latitude!  >  70  degrees  A  N'OTIIat  it  tide!  >  NO  degrees  A  /IMS\|(  )|  )\]/  $'(  ffldalS 

Tool-based  vs  Manual  Checks 

Prior  to  its  publication,  the  A-7  requirements  document  underwent  several  careful  reviews 
based  on  the  techniques  described  in  Ref.  19.  The  reviewers  were  NHL  computer  scientists 
(including  one  of  the  authors)  and  engineers  at  the  Naval  Air  Warfare  Center  in  China 
Lake,  California,  who  maintained  the  OFP  As  stated  above,  the  reviewers  overlooked  many 
significant  errors  that  our  tools  detected. 

That  errors  were  detected  should  not  diminish  the  credit  due  the  reviewers;  they  did 
an  excellent  job  given  the  large  volume  and  complexity  of  the  requirements  data  In  our 
view,  tools,  such  as  the  ones  we  built,  can  complement  the  efforts  of  software  developers 
Human  effort  is  crucial  to  acquiring  the  requirements  information  and  translating  it  into  a 
formal  representation.  Moreover,  after  errors  have  been  detected  in  the  specifications,  human 
intervention  is  needed  to  correct  the  errors.  However,  once  human  specifiers  have  developed 
a  reasonable  draft  of  the  requirements  specifications,  software  tools  provide  a  quick,  effective 
means  of  checking  that  the  specifications  satisfy  the  properties  of  interest  Not  only  are  tools 
more  effective  than  people  in  detecting  errors  of  the  class  described  above,  tin  availability 
of  such  tools  can  largely  eliminate  a  labor-intensive  task  that  humans  find  tedious  and 
boring.  (A  strongly  negative  view  of  the  review  task  was  expressed  by  review  participants 
in  interviews  conducted  after  the  completion  of  the  Darlington  certification  effort  |20|.j 

In  addition  to  their  utility,  another  important  feature  of  the  tools  is  their  low  cost  In 
the  Darlington  certification  effort,  which  was  estimated  to  cost  more  than  $l()M.  teams  of 
reviewers  manually  checker!  the  software  requirements  specifications  (and  I  hr1  code  spe<  id¬ 
eations)  for  application-independent  properties,  such  as  the  Mutual  Kxelusion  and  ('overage 
properties  described  above.  In  addition,  reviewers  looked  for  discrepancies  between  the  re 
quirements  specifications  and  the  code  specifications.  (This  is  the  first  class  of  verification 
described  in  the  introduction.)  Clearly,  tools  that  compare  the  specifications  with  a  refine¬ 
ment  are  more  complex  than  the  tools  that  we  built.  However,  that  does  not  dimmish  the 
value  of  our  simple  tools.  I’arnas  has  observed  that  the  "majority  of  the  theorems  that  arose 
in  the  documentation  and  inspection  of  the  Darlington  Nuclear  Plant  Shutdown  Systems" 
Were  simple  properties  and  that  the  reviewers  needed  to  analyze  10  kg  of  trivial  tables  for 
such  properties  |9|.  I  sing  tools  like  ours  to  do  such  checks  should  cost  far  less  than  using 
people. 

Related  Work 

Both  out  work  and  recent  work  by  Alice  and  Cannon  [21]  used  software  tools  to  analv/e 
SCR  requirements  specifications  The  two  efforts  differ  in  three  respects  First,  we  tested 
the  specifications  for  pioperties  defined  in  our  requirements  model,  whereas  they  tested 
application  properties.  Second,  out  tools  were  developed  inhouse,  wheraas  they  used  (  larke's 
model  checker  [  2  2 1  Finally,  our  tools  checked  two  kinds  of  tables,  condition  tables  and  mode 
transition  tables:  the  methods  in  Ref  21  were  used  to  check  mode  transition  tables  only. 
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Table  2  —  Transitions  Between  Alignment,  Navigation  and 
Test-Modes  (portion  of  A-7E  Mode  Transition  Table) 


Key  to  notation 


Symbol 

Definition 

Examples 

*  * 

Mode 

*1*.  *Eandaln* 

/.../ 

Input  Data  Item 

/ACAIRB/.  /IMSMODIl/ 

!...! 

Term 

Ipresent  position  entered! 

$...$ 

Enumerated  value 

$Sea$.  SGndalS 

- 

Expression  may  have  any  value 

@T.C«'F 

Event  of  boolean  expression  becoming  true/false 

t.f 

Value  of  boolean  expression,  true/false 
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Other  related  work  is  by  Pumas  and  Sit [ ,  International  In  a  recent  paper  |!t|.  Parnas 
describes  1()  small  theorems  related  to  his  tabular  notation  and  challenges  the  developers  of 
automated  proof  systems,  such  as  EYES  [2d]  and  PYS  [21].  to  use  their  systems  to  prove  the 
theorems.  I  wo  of  the  theorems,  the  Domain  Coverage  Theorem  and  the  Disjoint  Domains 
1  heorem.  are  slight  variat ions  of  t  he  ( 'overage  Property  and  t  lie  Mut  ual  Exclusion  I  ’ropert  v 
described  above.  SHI  researchers  accepted  the  challenge.  In  a  recent  paper  |2">j.  I  lies  de¬ 
scribe  how  nine  of  Pumas'  t  lleorems  were  proven  automat  ieallv  using  t  lie  Nee-st  rategv  "  <  tee's 
are  type-correctness  conditions)  of  SHI  s  proof  system.  PYS  |21l.  That  PYS  can  prove  such 
t  heorems  easily  is  not  too  surprising,  since  t lie  proofs  require  very  simple  logic.  What  is  note¬ 
worthy  about  the  PYS  experiment  is  that  the  theorems  were  proven  automat  ieallv.  ( 'learly. 
a  toolset  such  its  ours  should  be  lied  event  null  V  to  a  mechanic  il  proof  svstem  (eg  .  PYS  or  a 
similar  system)  that  encapsulates  some  subset  of  conventional  logic,  so  we  need  not  encode 
the  logic  ourselves.  Our  toolset  could  then  use  the  encoded  logic  to  check  specifications  for 
I  he  proper!  ies  of  interest 

CHECKS  DERIVED  FROM  THE  MODEL 

I  he  checks  performed  in  our  experiments  were  extracted  from  a  set  of  consistency  checks 
derived  from  our  formal  model  We  list  here  a  more  complete  set  of  consist etiev  checks  that 
can  be  applied  t o  tabular  specif ical ions,  organizing  t hem  into  t hree  groups:  Synt  act ic  ( 'hecks. 

I able-Speciiic  ('hecks,  and  Non-  1  ablc-Spccilic  ('hecks  Note  that  some  of  the  svntaetic 
checks  must  be  applied  oefore  other  checks  can  be  applied.  For  example,  tvpe  checking 
should  precede  a  check  of  condition  tables  for  the  Coverage  Property 

Syntactic 

I  It  esc  checks  test  :|i<  syntactic  correctness  of  the  tables 

•  Expressions  describing  conditions  and  events  are  well- formed. 

•  Each  tabic  entry  has  the  proper  data  tvpe. 

•  Each  controlled  state  variable,  term,  and  mode  class  is  defined  by  exactly  one  table. 

Table-Specific 

lor  each  type  of  I  able,  there  are  I  able- specific  checks.  Examples  include  the  t  wo  proper)  les 
described  above  (( "overage  and  Mutual  Exclusion)  that  condition  tables  must  satisfv  Listed 
below  arc  additional  examples  of  table-specific  checks,  each  applicable  to  inode  transition 
tables.® 

•  I-. very  mode  u  i  mode  class  is  in  ci t her  i  lie  "current  mode"  column  or  the  "new  m< ale " 
column. 

•  Each  inode  class  is  associated  with  exactly  one  mode  transition  table 

•  No  inode  is  unreachable 

Non-Table-Spocific 

This  group  includes  checks  that  call  be  applied  to  more  than  otic  table  I  lie  second  check 
listed  includes  the  check  Oil  the  mode  tinnsitioll  tables  described  previous!' 

•  The  initial  State  .,,,  is  unique  Initial  values  ale  lequucd  lot  ail  Inode  classes,  teillls. 
and  monitored  and  controlled  state  variables 

•  The  I  raiisforin  7  is  deter  lull  list  ic  Tills  requites  checking  bol  11  the  event  t  allies  and  the 
mode  transition  tables  for  iiondei ei mmism 

*  \  violation  <  fin-  t  It  n  •  1  jnojwrtv  i>  not  an  ••rioi  llmri*.  jts  violation  slinuM  i « u  1 1  in  a  w  atninp  i. it  Ini 
Ilian  an  »iit,i  mnssatv 
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•  There  are  no  identical  modes.  (Two  modes  are  identical  if  they  exhibit  the  same 
behavior.)* 

•  There  are  no  circular  dependencies  that  lead  to  contradictions.  (An  example  of  a 
circular  self-dependency:  ‘If  in  mode  m  the  event  x  -  a  occurs,  then  x  b.'  Circular 
dependencies  among  several  tables  are  even  more  difficult  to  check,  especially  by  hand.) 

CONCLUSIONS  AND  FUTURE  WORK 

There  are  three  conclusions  from  our  work 

•  Consistency  checkers  can  be  highly  effective  in  detecting  errors  in  requirements  speci¬ 
fications  Not  only  can  such  tools  find  errors  people  miss,  they  can  also  liberate  people 
from  the  unpleasant  task  of  checking  specifications  for  consistency. 

•  Properly  designed  tools  are  more  cost-effective  than  human  reviewers  for  doing  certain 
types  of  consistency  checks. 

•  The  formal  methods  on  which  our  tools  are  based  scale  up.  They  detected  a  significant 
number  of  errors  in  a  medium-size  real-world  specification. 

Our  plans  are  to  develop  the  formal  requirements  model  further  and  to  continue  exper¬ 
imenting  with  prototype  tools  based  on  the  model.  Work  is  currently  in  progress  to  add 
timing,  precision,  and  nondeterminism  to  the  formal  model.  Three  tools  are  planned,  all 
using  the  engineering  approach  described  in  Ref.  '26.  The  first  tool  is  a  consistency  checker 
A  second  tool  will  test  the  specifications  for  selected  application  properties,  thus  implement¬ 
ing  the  second  class  of  verification  described  in  the  introduction.  A  third  tool  will  derive 
simulations  from  the  formal  specifications;  the  definition  of  the  system  transform  in  Ref.  16 
provides  a  basis  for  building  a  simulator  of  SCR-stylo  requirements  specifications. 

We  expect  our  formal  model  to  provide  a  solid  conceptual  foundation  for  developing  re¬ 
quirements  specifications  and  our  suite  of  tools  to  demonstrate  how  formal  methods  can 
improve  the  quality  of  the  specifications.  High-quality  requirements  specifications  should 
significantly  reduce  the  costs  of  soft  ware  development  . 
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